Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Improve CLAP/CLI #47

Merged
merged 12 commits into from
Jan 19, 2020
Merged

Improve CLAP/CLI #47

merged 12 commits into from
Jan 19, 2020

Conversation

imclint21
Copy link
Member

@imclint21 imclint21 commented Jan 1, 2020 •
edited
Loading

Hi,

Like @Slals mentionned, the CLAP integration is not really clean, and this PR plan to fix this situation.

  • Remove author duplicates in cli.yml
  • Create an option to display/hide the banner

PS: opened issue here: clap-rs/clap#1617

Thank you

@imclint21 imclint21 added enhancement New feature or request help wanted Extra attention is needed core Core development labels Jan 1, 2020
@imclint21 imclint21 requested a review from shuni64 January 4, 2020 20:16
shuni64
shuni64 suggested changes Jan 5, 2020
View reviewed changes
Copy link
Contributor

@shuni64 shuni64 left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still needs the changes from clap-rs/clap#1617 to work properly. This somehow still compiles even though it shouldn't because we're using a yaml file instead of declaring the cli in Rust.

Also, there are help and version arguments that are generated implicitly generated by clap.
These were previously overridden by the arguments with the same name in the yaml file, but something should probably be done about them if they're supposed to be subcommands now.
Nevermind, they're still arguments. Would be better if the builtin version and help command were used though.

@imclint21
Copy link
Member Author

A guy from clap said me the it's possible to use template!

In reality, I would like to remove the banner from clap (ASCII art + description) and display it in the front of each calls but only if the option show_banner is set to true

@imclint21
Copy link
Member Author

@CephalonRho I see that you requested a change, but don't worry we will completely redesign the CLI :)

@shuni64 shuni64 self-requested a review January 19, 2020 12:12
shuni64
shuni64 approved these changes Jan 19, 2020
View reviewed changes
Copy link
Contributor

@shuni64 shuni64 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be fine to merge now.
I ported most of the CLI changes from split-cli but kept it in a single binary.
The tokens, store and cli subcommands have been removed since they didn't have any functionality attached to them.
I also added the -no-banner flag to hide the banner on startup and removed the author duplicates in cli.yml using anchors. Clap doesn't seem to have a better way to do this, but this is good enough.

@imclint21
Copy link
Member Author

Hi @CephalonRho,

I really enjoy your commits, especially moving to main.rs and also --config as global parameters!

For the banner, I prefer to display it in the usage message.

PS C:\Users\me\Projets\lucid> lucid
<< HERE
Lucid 0.1.2 << and remove this if it's possible
High performance and distributed KV store w/ REST API.

USAGE:
    lucid.exe [FLAGS] [OPTIONS] <SUBCOMMAND>

Another point, maybe we can show a link to https://docs.lucid-kv.store/ in help command.

@imclint21 imclint21 mentioned this pull request Jan 19, 2020
Closed
15 tasks
@shuni64
Copy link
Contributor

shuni64 commented Jan 19, 2020

I don't think it's possible to display the banner like that everywhere while still keeping the no-banner flag. The problem is that clap requires you to first define the whole CLI, including the template/name/version, and then matches the arguments.
This means that the program can't know if the no-banner flag is present until any help or error message has already been written to the terminal.

@imclint21
Copy link
Member Author

Hmm yes, I understand but is it possible to set the banner as clap name? it's a little bit tricky but maybe it can works.

@shuni64
Copy link
Contributor

shuni64 commented Jan 19, 2020

I'm not sure if specifically setting the app name to the banner is a good idea (subcommand names include the name of the app), but showing the banner is definitely possible. It's just impossible to consider the no-banner flag, so it will always be shown.

@imclint21
Copy link
Member Author

imclint21 commented Jan 19, 2020 •
edited
Loading

I think it's a bad idea too, but for me the name need to be optional, I don't understand why they [clap] do that like this.

For the banner, it could be good to have it in the usage and keep the parameter --no-banner for all commands, by this way, it could be possible to run the server without the banner, etc

Why do you think?

@shuni64
Copy link
Contributor

shuni64 commented Jan 19, 2020

Okay, the help message always shows the banner now and everything else still respects --no-banner.
The only place that doesn't contain the banner in some way is the version subcommand/argument, but it might get harder to parse the version if it contains a banner that can't be disabled so that's fine I think.

@imclint21
Copy link
Member Author

Don't worry version is good like this, I eat and review & merge!

@imclint21 imclint21 merged commit 198c44c into master Jan 19, 2020
@imclint21 imclint21 deleted the fix-clap branch January 19, 2020 21:13
@imclint21
Copy link
Member Author

@imclint21 imclint21 linked an issue Mar 10, 2020 that may be closed by this pull request
[Roadmap][Alpha] Lucid Alpha Roadmap #46
Closed
15 tasks
@imclint21 imclint21 removed a link to an issue Mar 10, 2020
[Roadmap][Alpha] Lucid Alpha Roadmap #46
Closed
15 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@shuni64 shuni64 shuni64 approved these changes

Assignees

@imclint21 imclint21

@shuni64 shuni64

Labels
core Core development enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@imclint21 @shuni64